IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3GPP) to provide IP Multimedia services over mobile communication networks (3GPP TS 22.228). IMS provides key features to enrich the end-user person-to-person communication experience through the integration and interaction of services. IMS allows new rich person-to-person (client-to-client) as well as person-to-content (client-to-server) communications over an IP-based network.
The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals (UEs) or between UEs and application servers (ASs). SIP is described in RFC3261. The Session Description Protocol (SDP), carried by SIP signalling, is used to describe and negotiate the media components of the session. Whilst SIP was created as a user-to-user protocol, IMS allows operators and service providers to control user access to services and to charge users accordingly.
Within an IMS network, Call/Session Control Functions (CSCFs) operate as SIP entities within the IMS. The 3GPP architecture defines three types of CSCFs: the Proxy CSCF (P-CSCF) which is the first point of contact within the IMS for a SIP terminal; the Serving CSCF (S-CSCF) which provides services to the user that the user is subscribed to; and the Interrogating CSCF (I-CSCF) whose role is to identify the correct S-CSCF and to forward to that S-CSCF a request received from a SIP terminal via a P-CSCF.
IMS service functionality is implemented using application servers (ASs). For any given UE, one or more ASs may be associated with that terminal. ASs communicate with an S-CSCF via the IMS Service Control (ISC) interface and are linked into a SIP messaging route as required (e.g. as a result of the triggering of IFCs downloaded into the S-CSCF for a given UE).
A user registers in the IMS using the specified SIP REGISTER method. This is a mechanism for attaching to the IMS and announcing to the IMS the address at which a SIP user identity can be reached. In 3GPP, when a SIP terminal performs a registration, the IMS authenticates the user using subscription information stored in a Home Subscriber Server (HSS), and allocates a S-CSCF to that user from the set of available S-CSCFs. Whilst the criteria for allocating S-CSCFs is not specified by 3GPP, these may include load sharing and service requirements. It is noted that the allocation of an S-CSCF is key to controlling, and charging for, user access to IMS-based services. Operators may provide a mechanism for preventing direct user-to-user SIP sessions that would otherwise bypass the S-CSCF.
Further signalling sent to and from the user is also controlled using SIP signalling. Each SIP client between the two end-points of the signalling uses the Domain Name System (DNS) to route the signalling and find the next hop to route the request. SIP uses several mechanisms for routing requests between hops. One of the key mechanisms used is rewriting the Request-URI in the header of the SIP message to the next hop to which the request will be routed. This will cause the original target identity in the header to be replaced with an address of an intermediate hop. The original target address is lost, and this can cause problems in scenarios where the receiver requires knowledge about the target address that was used to address that receiver.
For example, in the case where a single User Agent (UA) has multiple addresses associated with it, a single address is registered and the UA would accept incoming signalling sent to any of the associated addresses. It is desirable for the UE to know which of the addresses is being used when it receives, for example, a call, as it may play different ring tones depending on which address was used by the originator of the call. However, if the Request-URI is re-written then UA will not know which address was used to make the call.
Another example where the problem arises is in making a call for emergency services using Voice over IP (VoIP). A SIP INVITE request for an emergency must be marked to indicate that it is an emergency call in order that it can receive priority treatment. The marking is made to the target address of the request itself, to identify the target as being a recipient of emergency service calls. The Request-URI contains an SOS URN, which must remain in the Request-URO as the request is routed towards the emergency services target. However, this is lost if any of the intermediate nodes re-write the Request-URI.
More examples of scenarios where re-writing the request causes a problem can be found in Internet draft IETF draft-rosenberg-sip-ua-loose-route-01. The cases where Request-URI rewrites occur are as follows:                Retarget: In this case, the Request URI contains a new target address, and so the end target is no longer the original end target;        Reroute: In this case, the target address remains the same but a different or intermediary route is chosen to reach the same user, and so the Request-URI is rewritten to contain the routing address        Translation: In this case a name (URN) is translated to an address.        
The problem described above has been partly addressed by using the Route header, together with loose routing (http://tools.ietf.org/html/rfc3261). According to loose routing, the Request-URI is not overwritten, and so it will always contains the URI of the target UA. The SIP request is sent to the URI in the topmost Route header field, and so the Request-URI does not always contain the URI of the next hop to which the request will be sent. Effectively, the request target and the next route destination are kept separate in the SIP request header.
Another part of the problem has been solved on the last hop from a home proxy to the UA, in which a P-Called-Party-ID header retains the Request-URI value which had been replaced by the contact address of the registered user (see http://tools.ietf.org/html/rfc3455).
The internet draft (http://tools.ietf.org/html/draft-rosenberg-sip-ua-loose-route-01) proposes to extend the routing mechanism by extending the loose routing concept to the UE. However, there are several problems with this that need to be addressed. A simple extension of loose routing to UEs would not work unless the target node for the next physical hop supports loose routing. Each entity in the path must therefore know that the next-hop entity supports loose routing. If previous entities in the signalling path have used the loose routing mechanism, and an entity realizes that the next hop does not support it, it must “fix” the message by restoring the correct value back into the R-URI in order for that next hop to be able to process and route the message correctly.
Furthermore there are services that rely on receiving entities having knowledge of the “previous” R-URI that will only work if entities (which have nothing to do with the service as such) in the message path support the mechanism, which makes the usage of such services very limited and unpredictable.
Examples of scenarios in which the application of the loose routing mechanism to UEs would make the SIP routing fail include the following:
1. An intermediate SIP proxy (such as a Call Session Control Function in an IMS network) that does not support the loose routing mechanism. Such a SIP proxy would receive a Route header with one entry representing the proxy, and remove the Route entry. The proxy would then attempt to route the message based on the Request URI, using RFC 3263 procedures, and find the first proxy that the target identity resolves to. This would result in a loop back to the first proxy that the target normally resolves to, and so consequently routing would fail.
2. A Home SIP proxy that does not support the mechanism. In this case the home SIP proxy would receive a Route header with one entry representing the Home SIP proxy and remove the Route entry. The Home proxy would then analyse the Request URI to see if it is a registered Address of Record (AoR). Of course, it will not be and so the Home SIP proxy will attempt to route the message based on the Request URI, using RFC 3263 procedures. It will find the first proxy that the target identity resolves to, resulting in a loop back to the first proxy that the target normally resolves to, and so consequently routing would fail.
3. A Media Gateway Control Function (MGCF) that receives a request that has been routed using the loose routing mechanism may find a Uniform Resource Name (URN) in the Request URI. The MGCF cannot interwork with the URN and so call setup fails.